chdkfandomcom-20200222-history
Talk:UBASIC/TutorialScratchpad
TutorialScratchpad Help: talk pages, talk page guidelines Av&Tv Commands That are very handy commands, thanks for finding out! Now if we only could read out in "M" mode what the cam thinks are the best settings for Av and Tv, we could make a script where it sets the right values automatically for us. Since the CHDK I use "M" mode so much, because fixed aperture and time values are great if you use the histogram to get the optimal exposure. But it really bugs me that I have to try so much to get the right exposure, because the cam only tells me "-2" till "+2", but not the correct exposure right away. --Harvester 19:26, 17 May 2007 (UTC) :Nice to see you guys finding those values for the these commands found in the source code (I'm still not sure about the MOD and CALL ones though, no reply to my questions about them on the main uBASIC talk page). I put the first list of values you people found in a table, because I couldn't see it properly formatted in my browswer. Then I checked into more Wiki formatting commands (found another nice total list here How to edit a page, and couldn't get the monospace (typewriter/tt) fonts working on my browser. Come to find out I had replaced that font in my settings. Oooops. Now the pre-formatted text shows up just fine. Should I undo the table I made or just leave it in case others can't display a monospace font properly? :Keoeeit 00:21, 18 May 2007 (UTC) ::MOD is just the name of reminder (%). CALL is not used at all. -- GrAnd 07:52, 19 May 2007 (UTC) :::Regarding the table: I think both formats are okay. Perhaps I like the shorter format a little bit more and you can copy&paste it better into a text file, so I changed it back (if it is okay for you). --Harvester 08:17, 19 May 2007 (UTC) ::::re: MOD & CALL, thanks GrAnd. I kind of thought that's what the MOD was for but wasn't sure. I'll try to not add any "call" commands to my scripts too. :-) Then again ... a print "Call 1-800-BUY-CHDK" as a subliminal ad in every 15th intervalometer shot might work. :-) ::::re: Table, yep, looks much nicer. The more I saw that blunder the more I saw the blunder by trying a table to fix a font problem on my end. If nothing else, I learned lots of cool stuff about making tables in Wiki-speak. :-) Manual focus button on S3 IS Any chance of the manual focus button on the S3 IS getting a command? It is very hard to keep the camera absolutely still while holding down the MF button. 207.216.12.82 18:51, 18 May 2007 (UTC) :I see this functionality has been added through the addition of the press/release option and the mf button. Thank you, that was fast. I will credit your software when user. HighInBC 00:35, 9 June 2007 (UTC) (was 207.216.12.82) Operations order Keoeeit, you said: :Normally we assume that operations such as * and / will be performed before any + and - operations. This is not the case in this uBASIC. You will have to be careful on what order you put your math operations. Do you have the example in which you got the incorrect result? I've tested a lot of variants of combinations of math operations and as for me they work absolutely correctly. FYI... Order of operations --GrAnd 12:18, 19 May 2007 (UTC) ::Well, I don't have any examples anymore. You fixed what was causing the problem. :-) I was having a rough time trying to sort out a way to get those math expressions to work in a Print statement. And that's what lead to my belief that there was a problem with the math operation hierarchy. And yes, I realized after I wrote which came first + - or * / that I had them backwards, but wasn't quite sure. Math class was over 30 years ago. I've devoted those brain-cells to new things since then. :-) (Or lost them along the way, which always raises an interesting question, how can the brain know when it has brain-damage? Paradox. :-) ) ::I'll check the tutorial math section and remove that portion that warns of math operation disorder now. And I could simplify my intervalometer script now too, now that the print + math commands is fixed. I really should add in a complete "total time =" command figuring in shutter-speed too, now that the get_tv values are known, but it might be a tight fit to get that all under 2K with a shutter-speed table. I wonder if there's a simple way to compute shutter speed directly from the tv value? ::What might be handy is if we start a bank of commonly used subroutines that anyone could just dump into a program, shutter-speeds computed from get_tv might be a good one for that. Ex: my count-down timer subroutine in the Ultra-Intervalometer script might come in handy for others. Keoeeit 14:53, 20 May 2007 (UTC) Logic Expressions I'd like to add a section in the tutorial on how to use the &, |, and ^ (and, or, xor) commands, but I'm not quite sure I could do it properly. (My BASIC being pretty rusty.) But for the sake of argument, can these commands be used in situations like: :if a=1 & b=1 then gosub "both_must_be_true" :if a=1 | b=1 then gosub "any_are_true" :if a=1 ^ b=1 then gosub "only_one_is_true" And can these be used in more elaborate truth conditions, such as: :if a=1 & (b=3 | c=2) ^ d=1 then z=3 & y=5 else gosub "subroutine" ??? And do these also have an operation hierarchy? (priority of operation) Keoeeit 14:52, 20 May 2007 (UTC) :These operations (and, or, xor) are not logic. They are binary. --GrAnd 15:09, 20 May 2007 (UTC) IAQ - Infrequently Asked Questions :-) Is there (or will there be) any way that a script could detect which camera model it is being ran on? I'd like to modify the Ultra Intervalometer script to have one more toggle so it would engage single-frame shooting or video mode (now that the S cameras have those commands), but it would be nice if when that is engaged it would go to the proper subroutine per camera model to engage video mode. With something like: if i=1 then gosub "axvideo" else shoot if j=1 then gosub "sxvideo" else shoot Then again, if there's no way to detect camera model, there could be one user-value set as 0, 1, or 2, for single-frame, A-series Video, or S-series Video, or would that be too confusing for the end user? I wonder if one more subroutine to trigger the camera's own timer would be overkill and redundant? So many possibilities to play with now! (Plus the discipline of trying to keep it all under 2K.) Keoeeit 06:19, 27 May 2007 (UTC) : How about putting the scripts in Categories like: Generic, A-series specific, S-series specific? (btw: thank you for checking the whole wiki for the new changes. Good work!) --Harvester 09:06, 27 May 2007 (UTC) ::re: Categories by camera series -- Not sure how that would pan out in the future, with so many cameras supported, each having their own unique interface, etc. Hard to say what would be the best tack to take on it. Not a lot of people are submitting new scripting code either (yet), so I don't know if putting them by series on their own Wiki pages or what, would be the best route. I think this is one of those "time will tell" thingies. I'll eventually add in the video toggle for the Ultra Intervalometer script, but the more I thought about, I realized I'm limited to 10 user definable variables too. (single letters at that, I'm running out of variables) I already used up 7 of them. :-) Now add in a Video toggle and I have to add script to set the duration for video too. There's 2 more user variables. 10 shot to hell already. Then I thought, I'd really like if if you had the option to take a full-frame shot before or after each video sequence as a documenting mode, as yet another option. Ooops, that's 11 variables. I'll think of sumpin! :-) ::re: the S-series button edits, I think I found them all, but if you spot one I missed feel free to change it. Keoeeit 04:07, 28 May 2007 (UTC) ---- Super quick question I couldn't find an answer to: how do you go back to the default script? Should I create a blank script with no functionality? Hope this is the best place to post this... --24.89.200.199 19:30, 12 September 2007 (UTC) Camera Operation Commands I think the section "Camera Operation Commands" could need some differentiation, like this: * commands (shoot, click, press, release) * the other "thing" behind the command... the buttons... you know what I mean (left, right, menu, display etc.) --Harvester 14:43, 2 June 2007 (UTC) ::Let me know if doing it the way I did was clear enough, if not and something seems confusing, or I shouldn't have used those graphics in the opening section, feel free to clean it up. My theory is always provide too much information than too little and let the receiver filter out what they need, rather than letting them guess on what wasn't said. As for the commands, some of the buttons should never need to use the press/release sequences (like erase, menu, set, etc.), even though press and release can be used with them (I presume). Since I'm not familiar with cameras other than the S3, I don't know what creative ways some might find for using them. So I prefaced them all with the click/press/release options. I now await the influx of amazing new scripts that everyone is going to share. (ya think? :-) ) Last night I got home late from a 16 hour fishing trip on my mountain bike, and rode the last 8 miles home in the dark on muddy dirt roads in pouring rain (4-lb bass on ice in saddle-bag), so the best I could do when I discovered the new press/release commands last night was update the "Focus Bracketing" script and test it on the S3, worked fantastic! (then I passed out and woke up 9 hours later) You have an A-series camera, correct? Can you modify or test that script and either add a confirmation note or add an A-series script if the one that I have up does not work on A-series? Keoeeit 18:57, 2 June 2007 (UTC) Dark-frame Subtraction not ALWAYS at <=1.3 seconds! I found out something interesting tonight, and I wasn't sure where to post this, but it could influence a lot of scripts that might already be or will be written. I was fooling around trying to find out the best ways to implement some button commands on my S3 IS, which meant I was really putting the camera through its paces with all sorts of things. At one point one of my scripts goofed up using a press "zoom_in" ... shoot sequence when I found out it was far far better to use a sleep delay with a press/release zoom_in command than a click "zoom_in" command. The interesting thing was that I actually got one photo to take a shot DURING a zoom, creating an honest-to-goshes zoom-blur image! I couldn't replicate this in a stand-alone script, but this is beside the point.. Anyway, I later went to go put some tweaks on the Lightning Photography script for the S3 IS, trying to make it even nicer, having it use a press "mf" / sleep-x / release "mf" command to set the camera to infinity focus. After a few times of running that script i noticed that my 1-second frame rate got SLOWWWWW... and I was getting the typical "busy" in the view-finder for a dark-frame subtraction taking place. Uh oh, I thought maybe I found the very first occurrence of CHDK goofing up my firmware. It was doing dark-frame subtractions all the way up to 1/6th of a second! Only when I put it to 1/8th of a second would the dark-frame routine cease. I went to go find another SD card without CHDK on it, I even removed the little button battery to reset my camera's firmware. Then I was able to get 1/6th seconds without a dark-frame. I thought, awwww $#|T, I bet I busted something, oh well, the rest of everything works just fine. Then I got the idea of something ... I opened up the LCD display on the back and felt the back of the camera, it was VERY warm from all I was doing with it. I wondered .... could Canon be so smart as to increase the dark-frame subtraction as more thermal energy was causing more noise??? I let the camera set a while to cool down. I have my no-dark-frame-subtraction back again at 1-second shutter speeds. Too much heat from over-use (or leaving it in a warm place) will cause your dark-frame routine to kick in at higher shutter speeds! I wonder, if you put your camera in the fridge for a bit if you could get dark-frame-free exposures at shutter speeds even lower than 1.3 seconds? I may test this. What a boon that would be to astrophotography in the winter months! (I wonder how cold the camera would have to be to have no dark-frame subtraction at 15 seconds. :-) ) So, I didn't know where to post this anecdote and findings. I discovered a lot about the script commands as well as the dark-frame routines tonight. Perhaps someone can say this in a more concise way and post it where others might see it. Maybe put in a note that if running lengthy scripts where you need no dark-frame-subtraction to kick-in, to open up your LCD panel on the back (un-lit) so the camera body can keep cooler. p.s. I found it's much better to use a press/sleep-x/release "timer" sequence than a click "timer" command. Less chance of the command not getting implemented while the camera is busy setting exposure and stuff. So those press/release commands are going to come in more handy than I first thought. The press "zoom_in/out", sleep-x, release "zoom_in/out" is another good way to use them, MUCH faster than a for/click "zoom_in"/next loops! Keoeeit 11:54, 6 June 2007 (UTC) :Yes. I heard that Canon uses thermistor to measure sensor temperature to make a desision on dark-frame substraction. This mechanism exists in my A610 as well (the minimum Tv is the same - 1/6th). In the same time if Tv >= 1.3s the dark-frame substraction is always performed. So, you can't avoid the dark-frame substraction at 15 seconds even if you put your camera into a freezing room. :) --GrAnd 13:36, 6 June 2007 (UTC) ::Ah, thanks for confirming what I observed and the further info on it. This will save me from putting my camera in the deep-freeze in a desperate attempt to get rid of the dark-frame routine. Or tying a block of dry-ice on top of the camera. :-) You would think they could mention this in the manuals or something. It was a bit disconcerting at first. If I notice a good place to mention it in the main Wiki scripting info I'll do that since it's not documented elsewhere. I notice you just updated CHDK, I have to go grab my copy and check it out. Thanks-again for the info! (AND CHDK!!) :-) Keoeeit 21:50, 6 June 2007 (UTC) :::Very interesting, thanks for the S3 IS info. HighInBC 14:10, 11 June 2007 (UTC) Deterministic ISO settings Is there a reliable method to set the ISO to a deterministic value? I want to initialize as many settings as I can to specific values in the beginning of my script. The only way I've found to set the iso value is by click'ing the 'ISO' button, and since it rolls over, you can only set it relative to the initial value. (for instance, if the ISO began at 100, if you click 5 times, you get back to 100 (100->200->400->800->80->100...)) But I haven't found a way to guarantee I have it set to 80. Poking around in the source code, there are tables defined for the shutter speeds, aperture and ISO values. There are set_tv and set_av to set the shutter and aperture, but no equivalent for setting ISO. Is a 'set_iso' operation possible/in the works? An alternate possible approach would be to use some sort of 'reset' operation to reset everything to some known default value, and then go through and set everything to the desired settings. Any suggestions? CHDK is great! Thanks! Get_Focus X? This request is now obsolete due to Build 125. :-) but I'll leave it in for the info about the S3's SET button + MF feature, someone might make use of that some day. GrAnd? I read somewhere that it is easy for you to read the manual focus position but not set it. Would it be possible for you to implement a simple get_focus command. With this I can see all kinds of ways where a near-exact focus distance could be set. For example, in the S3 IS camera it could be done with: rem set manual focus to nearest possible on S3 IS press "mf" press "down" rem 8 seconds is needed for full manual focus travel at highest zoom setting sleep 8000 release "down" rem Going to set manual focus to 1256 mm :coarsefocus get_focus x if x>1200 goto "finefocus" rem increment the manual focus a bit each time it loops press "up" sleep 10 release "up" goto "coarsefocus" rem Fine-focus routine :finefocus get_focus x if x>1255 then goto "shootpic" click "set" sleep 100 goto "finefocus" :shootpic whatever code you want after focus is very very close The sleep commands would have to be tested, but as long as you can detect what the focus position is, then it's possible to stop the manual focus position where it needs to be. In the S3 IS in MF mode you can press the SET button for fine-tuning manual focus, and it always works from near to far (in micro-increments) until it locks on something with high contrast. This is how you could emulate a fine-focus mode. Keoeeit 19:26, 11 June 2007 (UTC) Consolidate the original Syntax & Tutorial Pages? When this all started out, and GrAnd put together the preliminary pages for us to get this rolling, I started this "Tutorial Scratchpad" page (because I didn't know what I was doing yet/still :-) ) with the idea that sections of this scratchpad page could be eventually copied and pasted to GrAnd's original uBASIC Syntax page. Well, it seems that it just got easier and easier to add on to this one by me and everyone else. I still like the way GrAnd described some things so I thought his page should always stay. But I think it's getting to that point where his original page should be consolidated into this one (or vice-versa), and the final page renamed to, perhaps, just "Script Tutorial", or "CHDK uBASIC Scripting" or something like that, or ... I don't know, whatever would be the most correct title to use. And would this require putting it all in a new Wiki page with the right path-name in it? Or can a Wiki page/path be renamed? So, would anyone like to take a stab at how to do all this? I'm wondering if GrAnd's page could be put in as a header section where the "Starting Out" info was put. His shorter summation of the commands available with the the rest of the tutorial following. As well as taking his script examples and peppering them in places where they might be the most applicable. Comments? Suggestions? Is this needed or not? Anyone want to step up to the plate and do it? :-) Keoeeit 16:37, 12 June 2007 (UTC) set_zoom problem This is odd, because it was working before. I would use the script: set_zoom_speed 50 set_zoom 61 end to set the zoom to a specific point for a shot I wanted. It worked, several times. Now when I do it, the camera goes to the correct zoom level and automatically stops. I read about how this can happen with a zoom speed of 5 or less. But I tried 100, 50, and 10 with the same results. Could there be another explanation to the behaviour? It would be my HDR mosaic photography if I could instantly set my ISO, Av, zoom, and focus. But I just can't get past the zoom setting. HighInBC 22:35, 30 June 2007 (UTC) BATTERY VOLTAGE Can I use a command to read the battery volage and then perform another command depending on the voltage or voltage change? :This has been added by Microfunguy's SDM, and Fingaolo's special builds. See the Scripting Tutorial in the Camera Commands, Special Builds sections. Motion Detection Version? I asked some questions about it in another spot in this Wiki. I'm not sure if it will be seen there so posting a link to that question here: Motion Detection, add to the Tutorial? :Situation resolved. :-) Access to Real time clock? Is there a function to retrieve the internal real time clock value? In attempting to deal with the timing of intervalometer scripts, it seems like so many factors can affect the overall interval time. The sleep function used to space the interval needs to at least estimate what the those other things are (exposure time, time to set focus, time to determine exposure, writing to card, dark frame subtraction time, etc). All of this guesswork and mode- and conditions-specific variability could be ignored if the script could fetch the RT clock value, and just shoot at the appropriate time. If there is not such a function, could I get it onto the wish list? Something that returns an integer equal to the time of day (in msec, or whatever units the camera uses). Thanks, Divalent ERASE COMMAND, and other problems hi, if recently, 3 days ago, came across CHDK....... and i love it . thats why i decide to give an comment here.... most of the scripts wont work if u not put the cam in a certain situation(condition).... one of the most common faults i found is the use of the erase command... if this is used and in the config the raw shots are enabled the cam is getting totally confused and crashes... HOW to prevent this ... what makes me suspioues that I couldnt find any hints nor comment about this in the scripts descriptions... the next problem i discovered is that some of the scripts are using divisions where the result is NOT an integer that even hangs up the cam even...As far as i understand uBasic its needed INTEGERS to work proper... the fact of this problems and none descriptions of the unknown cam settings where its been used make the most scripts non usable and a newbie like me gets puzzelt quite a bit... overall i think the idea of the script is a good way which needs to be adjusted a little bit to make the program even more unique then it is allready.dont get me wrong I love it....it is awsome except this small matters ...... is there any solution or chance to corect this... like reading the parameters out of the cam and let it run into an error trap.. like its used in MBasic or other basics .... something like on error goto... i havent enough knowlege yet but i guess the cam gives out some errorcodes in the memory or firmware ........ any suggestion....... many greatings from germany ... hells_bells27 :I've never noticed this integer-only problem that you seem to be having, and I've written and tested many scripts using divisions that result in non-integer values. The non-integer values from any calculations are always rounded to integers whenever they are used in any resulting variables for camera commands and print statements. Perhaps you are just copying the scripts wrong? People using Mac computers frequently have this problem. Or those that use anything other than the simplest of text editors. This is the first time I have every heard of anyone thinking this might be a problem, i.e. integer/non-integers in scripts. I've also never ran into an erasing files causing crashes. You might have to explain in detail exactly what you are doing that causes this so that others might be able to duplicate it. Be sure to also state what camera and build of CHDK you are using. That can make a huge difference. I have found the problem.... it is depending on the script delay parameter... i have tested with my A630... if the script delay is below 4 msec. then i have this obove described problems... so i set it now to 6 just to make sure its running on all of my SD.Cards well.... thanks for your answer.... btw. if u set it up to 6 msec. u dont need the sleep command as much as usually... this saves a lots of processing time... kind regards HB Property Case values. A working exploration section Some inital tests related to the property case values. UPDATE: I found the focus bracket controls. It is property 36, BUT, it is only active if you activate Manual Focus. see below. (38 controls the range) This section is for exploring the values stored in these variables and the effect of changing them to different numbers. Please help out and add info from more camera's and more properties! You can find an a more extended list here: this page of Property Case IDs (thanks to Mr Anon for finding this list, which was already on this site!) You MUST use either Fingalo's CHDK build or a pre-release version of 'StereoData Maker' available here . (An example-script is provided with SDM that cycles through the white-balance settings using set_prop command). I used the script I posted in the user scripts page to test some of the property case values. (You can find that script here: Property-Case Value Tester) [Note: I focused mainly on the property cases that others have identified, although I did discover #32. and #36. I will also note that at least from 260 to 512 everything I saw was a 0. But there were lots of properties below that had non 0 values (some of them changed moment to moment; probably auto focus or exposure settings) I tested these on an S3, mostly in P-mode. Here's what I've found so far: For the following "properties" here are the values I obtained: 0 Shooting mode dial ------> See comments below** 2,3,4 sharp, sat, contrast--> Custom MyColors. See details below 6 Drive mode --------------> 0 - single, 1 = continuous, 2 = timer 8 Hi-speed continuous------> 1=OFF (!), 0=ON (!) 9 Metering mode -----------> 0=eval 2=center, 1= spot 10 Spot AE Point -----------> 0=center, 1=auto focus point 11 Macro -------------------> 0,1,5 for norm, macro, and super 12 Manual Focus -----------> 1 = manual, 0 = auto 14 Selftimer delay ---------> time in msecs 16 Flash mode --------------> 2 if flash closed (down). Otherwise, 0=auto, 1=ON 18 Red eye mode ------------> 0=OFF, 1=ON 19 Flash slow sync ---------> 0=OFF, 1=ON 20 Flash Sync Curtain ------> 0 = first, 1 = second 21 ISO value ---------------> 0=auto, 1=ISO-HI, or actual ISO: 80,100,200,400,800 23 Image quality -----------> 0,1,2 from best to worst 24 Image resolution --------> 0,1,2,4,8 for L,M1,M2,S,W 25 EV correction -----------> plus or minus 32 for each 1/3 stop (in other words -32 for -1/3 stop, -64 for -2/3 stop, -96 for -1 full stop, etc, and positive values for over exposure by equivalent amounts) 26 EV correction -----------> (same as #25) 28 Flash comp --------------> same as 25: 96 unit/stop for +/- flash intensity 29 Manual flash intensity --> units 0,1,2 (where 2 is full intensity?) 32 Exposure bracket range---> (Same units as 25/26: e.g. 96 = +/- 1 stop range) 34 Focus bracket range------> 2=Smallest, 1=Medium, 0=largest 36 Bracket mode-------------> 0=NONE, 1 = exposure, 2 = focus (see below) 126 Video Frame rate---------> Units of fps (e.g. 30) *beware of changing! 127,128 Video resolution-----> 2,1 for 640x480; 1,0 for 320x240 177 intervalometer #of shots-> Actual number 206 MyColors" mode ----------> 0=OFF, 1-11 for various (see details below) 207,208,209,210 -------------> Custom MyColors, see details below Some comments and usage suggestions on some of these: #Property 126, video frame rate: changing this to an non-standard value did not work, and locked up the camera. For now, avoid. tried changing the Video fps to 10, and it behaved strangely (time counter went really fast) when I started a video, and then the camera crashed when I stopped the video. The video was not saved on my memory card. I also tried 60 fps at 640x480 mode, and the thing went haywire. I'd hold off on expecting to get anywhere changing this parameter. Beware! #Property 6, drive mode: changing this value sometimes has an effect, and sometimes not: if you change it to continuous mode when bracketing is not set, then it does not work: if you hold down the shutter, you only get one image, not a continuous stream. However, if you had previously set exposure bracketing (manually, not by set_prop), then changing 6 to continuous mode does have an effect: when you press the shutter, it will do a 3 shot exposure bracket. Also, setting this to "timer" (2) also fails to activate the timer. (but it does tell you the state, so you can use button pushes to change) #Property 14: changing the Selftimer delay here does NOT alter the actual time delay. Use this only to get the time (use button pushes to alter). #Property 16, Flash mode: with new info in any mode (P,M,Tv,Av) setting this to value "2" essentially turns the flash off. In P mode (on the S3) you can force a flash even if in flash-auto mode (value 0) by setting this to 1. (of course, all of this is moot if the flash is down). on the s3, if you are in AV,Tv, or M mode the flash is controlled only by whether the flash is raised (it will flash if up). I.e., there is no "auto-flash" setting. In P mode, the "auto-flash" mode is active. #Property 28: for all modes except M, this property can be used to adjust the flash intensity +/- several stops. Note: in all but M mode, the camera is making a decision how strong the flash will be based on the image. This property adjustment allows you to go +/- that amount. The built-in camera range is +/- 2 stops. I haven't tested what happens if you go beyond that range. Also note that if you set the main menu flash adjustment setting to "manual", or if you are in M mode, then the flash intensity is instead control by property 29, in units of 0,1,2 (where I think 2 is the full flash capability). (where is the property that indicates where the auto/manual flash compensation setting?) #Properties 25 & 26, Exposure compensation. Setting these will extend the range of an S3 exposure compensation to beyond the normal 2 stop limit. The most I tried is + and - 4 stops (using 382 and -382). Note: For 25 and 26, I'm not sure why there are two of these, and I'm not sure what would happen if you change one but not the other. (when I played with it, I just set them both to the new value and my suggestion for you to do the same until someone clarifies this further). #Property 32, the bracket exposure range, it does work using 4 stops (i.e., setting exposure bracketing in the menu, then set #32 to 384, then either manually setting continuous mode or setting #6 to "continuous" mode, then press the shutter and you get a 3 shots -4, 0, +4) #Property 36, the bracket mode. It does not appear that changing this property by set_prop will have any effect. You apparently have to do this manually or with button clicks. The values 0,1,2 correspond to none, exposure, and focus. However, for the focus bracket, it is ONLY active (it only reports "2") if you are also in manual focus, otherwise it reports "0" (and you only get a single shot). #Property 34 sets the focus bracket range, and changing this does, in fact, alter the bracket range. However, the fact that "0" is the high end on the focus range means it may not be possible to extend it beyond the current maximum range (I did not try using -1 !). #Properties 21 (ISO), 23 (image compression), and 24 (image size/resolution), changing these to valid values for this camera seemed to work fine (I didn't try all, and didn't try non-standard values). #property 177 is 0 if you have not activated the intervalometer mode. Otherwise, this contains the number of images in the sequence. (I haven't found the duration yet, and haven't tested to see if this can be more than 100. If so, would be good for longer sequences (since the camera powers down between shots with the built-in routine)) #Property 0, shooting mode dial position: the values I got for the mode positions Auto,P,Tv,Av,M were -32768, -32764, -32765, -32766,-32767. The other positions also had different values (but I didn't catalog them). In Hex, these numbers are FFFF8000, FFFF8004, FFFF8003, FFFF8002, and FFFF8001. I leave it for someone else to sort out. (In the back of my mind I have this worry about the size of the parameters, and the effect of writing a DWORD into a slot that may only be a byte, because if prop 0 is just a byte, then the result is 0,4,3,2,1) "My color" controls Property 206 controls the mode of the "my colors" setting. Here are the options for this property: 0 = OFF 6 = lighter skin tone 1 = Vivid 7 = darker skin tone 2 = neutral 8 = vivid red 3 = B&W 9 = vivid green 4 = septia 10 = vivid Blue 5 = positive film 11 = Custom If you set "custom" (value 11 in 206), then the values in the following properties set the "Custom MyColors" attributes: 2 Sharpness 207 Red 3 Saturation 208 Blue 4 Contrast 209 Green 210 Skin Tone (+=darker) All the above properties (2,3,4,207-210) have the same range: 254,255,0,1,2 from less to more (skin tone I believe is darker with higher numbers). NOTE: these property values are actually byte values, but I believe the current (oct 16, 2007) version of get_prop is returning a 2 or 4 byte word. 255 and 254 are actually -1 and -2 in the byte format. Note: these values are static (i.e., they don't reset or change if you change the mode to something other than "Custom"), so it does not appear that you can use these as enhancements to one of the other pre-set modes. In other words, these custom values only have force if you are in custom mode. ----- I didn't try to change 9,11,12,or 14. Question: WHERE IS THE FOCUS BRACKET CONTROL? Found! Suggestions for some other things to try or to look for: - a property that would increase the number of images taken in a bracket series from 3 to 5 (7? 9?). I did see a number of properties that had a value of 2 which I was unable to change by changing other settings using the menus (I was hoping to find the focus bracket setting). It might be interesting to try using the set_prop to change to 5, and see if you get 5 images in a sequence. (later note: my thinking may be confused here; should be looking for 3s, not 2s. but still a useful thing to search for. found only one property set to 3 (#181), and changing it to 5 did not affect number of shots in a bracket) - a property that specifies the current position in the FUNC menu hierarchy (or would allow you to reset it to a known position). Currently you can access many of the items in the FUNC (at least with an S3) by doing the click ERASE (which is FUNC on an S3), then up/down/left/right etc clicks to go to particular items. Unfortunately, when you exit the FUNC menu and then return, the "cursor" is in the same place you left it at. So you can't reliably change a FUNC menu item unless you know where it will be when you activate that control. - If mode-dial prop-id values are set, does the camera behaves just as if set into those modes? (e.g., in P mode, but set_prop go to M. Does it behave as if the dial is fully in the M position?) anon - A huge reward has been offered to anyone finding the Image Review time control. :) A comment about the state of the camera when using these. If you change a value and then exit the CHDK mode (using the shortcut button) the camera will take images using the changed values. However, the camera displays (and the menus) did not show these changed settings/values. Rather, they show the original setting/values before they were changed. Turning the camera off, then back on, did restore the settings to back to their original values (before changes) so that they reflected what the camera display said they were. (also, it appears that entering display mode, or changing the mode dial (P/AV/TV/M) has the same effect of resetting .) So, if you change these items in a script, it is probably a good idea to change them back before exiting, or your camera will be confused. (Note: I've trimmed the comments some since the information asked for or gotten is now up above. Commenters are encouraged to trim further. Use the page history feature to see what was there as of Oct 15, 2007) -Divalent :Most excellent testing and sleuthing there Divalent!! Thanks!! This information will be extremely valuable to add to the pages. You might want to go ahead and add them to the set/get_prop section now. With a note of what camera model you have found them to be correct on at this time. :This is the same way that people who were testing the various set/get_av/tv values were found for different cameras (see that section, examples still intact there). One person posting theirs encouraged other camera-model owners to test theirs. Some discrepancies were found and it resulted in some minor changes to the look-up tables in CHDK so all cameras would have the same values. :...I still wonder if non-standard resolution and frame-rates might not be available hidden in the secrets of these cameras. Hmm... I wonder if a prop_id will be found for audio-recording settings too. Or maybe even the sound-memo length (as was asked as a request recently). So much to discover yet. :-) :anon ::I've only tested 10 and 60 fps, resulting in crashes. I'm not in a mood to try more, but if anyone else wants to try 50 or 27 go ahead. :(Regarding why there are 2 EV compensation settings 25&26) I'm not sure either why there might be 2. But when writing scripts I did find an interesting aspect to the Av and Tv values. It appears that the one being detected and the one you set are two very different things. I can't remember the exact situation in what caused this, I found it when trying to write the Lightning Photography scripts. Using the set_av/tv commands. When I saw that the Prop_ID values listed the Av/Tv as "coming Av", and "coming Tv", it sort of reinforced what I sensed was going on. Maybe these 2 values are used similarly? One for manual settings, the other for auto-detected settings? Just a vague guess. As far as their use, it wasn't clear from your list if the numbers -32 to +32 are used to set 1/3rd stop or what, or if the full range of numbers is -96 to +96. And if that's the case, can they be extended to change the stop by 2 or more for HDR frames? How far can those numbers actually span? mr.anon :Do you know what that exposure bracket range is for? I'm now wondering if that's set by a quick script if it will increase the manually selectable range on-screen. ... anon ::The exposure bracket range selectes the range overwhich your 3-shot exposure sequence will shoot. Camera limits it to +/- 2 stops (beyond any Ex comp value you set (so you can get below 2 stops OR above 2 stops if you adjust both). If you set the ex bracket property value to 4 stops, the menu selector still shows the original value (and you don't see an extended range). My experience with iso, exp comp, IQ, etc, is that what the camera display menus show you after you change something is what it was before you change it, not what you changed it to. There seems to be another storage place in the camera for what is displayed. Also, I'll note that if you change into display mode, or manually change the mode dial (P,Av,Tv,M) then everything get reset to the original values (I wonder if changing mode property 0 also does this "reset"?). :re: exp. brkt. range, now that's sweet! Seeing as how the built-in exposure bracketing is much faster than any done by script ... this could provide for some excellent new, FAST, and short EV scripts!! People that do HDR sequences often claim needing 2+ or more stops per exposure, some HDR blending software even requires it for best results. I'm now wondering if that will effect the range of the Focus Bracketing steps too, or if there's another Prop ID for that. As that sorely needs more range on it, that's what pressed me so much to find some decent focus bracketing methods. Dearly needed for macro photography. When I first got my camera it was even difficult to tell if there was any difference between the 3 focus-bracketing images created by the camera (yes, when set at the maximum +/- range for it). ::a suggested script for extended range and more images: set exp comp to -1.5 stops, do a EV bracket of over a 1 stop range (getting 3 quick), then set exp comp to +1.5 stops, and do another quick EV bracket of 1 stop; Result is 6 images 1 stop apart from -2.5 to +2.5 :I'm afraid to ask what happens with the focus/exp-brackets set. :-) I know they can come in handy in scripts though. With a focus bracket script, and setting the camera to exp. bracket, it'll take 3 shots per focus step, really handy. I hope you or me or someone stumbles on the focus-bracket Prop-ID. I've since added what you found so far to the Script-Writer's List so at least it'll be partly available so far on the main page. It needs more updating though, I left out some one of Fingalo's easier ways to use USB remote. Those findings for #32 and #36 are great! I'm also thrilled with what you found about flash compensation. Who'd have thought you could set the flash output by 96 levels. There's some major precision buried in these cameras! This has me wondering now, about turning flash to such short (dim) durations as to stop really fast objects (would have to be near subjects), or its usefulness for macro-flash modes ... A640 : I tried to use the 32 and 36 properties expecting that the firmware in A640 would have a hidden functionnality for bracketing > it fails to work ... a pitty. As the #25 and #26 properties are working fine too on A640, I'm hunting the "review time" property. For this I've written this little script which only acts on the display menu (hit menu, goes up 3 times, press left, hits menu again) then it compares the value of a property to its previous value and prints it if they are different. So far I've run this script from #0 to #300 and didn't find any change but #100 and #101. I've noticed that #100 seems to be affected by the changes in menus or button press but I'm not sure. I'll go on running this script on upper values of properties and keep you informed. Here is the script : @title cherche @param a propid @default a 0 @param b value @default b 0 for a = 98 to 300 sleep 500 click "menu" for s = 1 to 4 sleep 500 click "up" next s sleep 500 click "left" sleep 500 click "menu" sleep 500 get_prop a b n = b click "menu" for s = 1 to 4 sleep 500 click "up" next s sleep 500 click "right" sleep 500 click "menu" sleep 500 get_prop a b if n <> b then print a, b, n next a end Alain Lightning Photography with Motion Detection? I asked about this in the page where the Lightning Photo samples are being posted. Please refer to Lightning Photography Discussion page if interested in helping finding the best way to do this. I would like to add the best script possible to the scripts section once all the bugs are worked out too. I asked there because it seemed like the place where the most who were interested in that subject might find more information about this aspect of using CHDK. uBasic timing. One line (only!) executed every 10 msec? I was playing with Fingalo's test CHDK (a special secret version) that has a get_tick_count function (I think written by Mike McCade) that returns a time in milliseconds. In testing it, it revealed (I think) that a uBasic script will execute one, and only one, script command every 10 milliseconds. Heres the situation: with the following script: a = get_tick_count b = get_tick_count print "counts were", a, b a and b are always (ALWAYS) 10 milliseconds apart. (they both also always (always) end in a 0 (e.g, 25670, never 25671, etc)) That got me to testing further: if I put 3 other commands between the get_tick_counts in there, like this: a = get_tick_count b=b+27 <---| c=c+a <---|---note: these 3 don't do anything other than make uBasic execute a command d=d*23 <---| b = get_tick_count Now a and b are now always 40 msec apart (never 30, never 50). And even REM statements take a 10 msec chunk! a = get_tick_count goto "jumper" rem :jumper b = get_tick_count (a->b is 20 msec, so "goto" = 1 command (regardless of what it hops over) rem blank line c = get_tick_count (b->c is 20 msec, so REM = 1 command (10 msec!) rem executed line below d=d*73 d = get_tick_count (c->d is 30 msec, REM + multiplication = 2 commands It looks like uBasic executes one, and only one, command every 10 msec (on the "0"). (moreover, it looks like uBasic is called on an interrupt that trips every 10 msec, so that's why the tick_count always ends in 0). And even REM statements count as a command! (On the bright side, a blank line does not count. so space those lines with blanks, not blank REMs!) Script writers developing timing-sensitive scripts should keep this in mind. Comments? -Divalent :I think this is true of any programming, and something to always keep in mind. The difference between bloatware that requires a new computer every year, or efficient programming that still runs on a computer from 5 years ago. I recall from my BASIC programming days that code is reinterpreted from beginning to end with every result required (thought that may have been just the OS and CPU I was running on at the time?). This is why I find it important to keep rem statements to a minimum, and to find more efficient ways to create loops, counters, etc. Include a few rem statements between your test lines, see if that too doesn't increase the time required. I have also found that the earlier and smaller builds of CHDK are faster than later ones. I keep them handy in sub-folders on my SD card for intervalometer scripts where I might require the fastest speeds possible between frames. I also keep the original RAW hack file because that is the fastest of all if only needing RAW images and no CHDK interface. I haven't tested it yet but I think the in-camera copy commands can replace the *.fir and *.bin files from my backup subfolders of earlier builds when really needed. Just as long as I don't move a version of CHDK to the root of the card that doesn't include the move/copy commands so I can "upgrade" back again when needed. :) :: Well, that was my first initial impression as well. But I think I am describing something more than just slow because its an interpreted language. The clock is dead accurate in that you can use the time between two fetches of the tick_clock and the difference is *exactly* equal to 10 msec times the number of uBasic lines executed. I followed up and tested REM statements, (see above) and even they count! (and a GOTO is one, even if it's hopping over valid lines of code) This is WAY too slow (and far too accurate) to be considered 'normal' processing time. :: The conclusion is unmistakable, uBasic is allowed to execute only one line of code each 10 msec. That might make sense for a device whose primary purpose is to be a camera and image processing unit; to only give parasitic processes a limited time slice. But it is far larger a penalty than I thought existed. :::Interesting findings. I think I should make a note of this at the top of the tutorial page, as a reminder to those writing scripts to be efficient in their coding. Considering, as you say, this is a CAMERA!, I don't think we should be asking for major pentium dual-core CPU miracles here. I'd be happy if all it did was push the shutter button for me from a simple 3 line looped timer where I could change just one variable. :-) ::::Undoubtedly uBasic works by executing a line of code, then relinquishing the CPU back to the camera, and then doing a new line when the camera calls it again (10 msec later). (I say this not having actually looked at the uBasic code, so I could be wrong). This probably is very rational, particularly when a function is time consuming, so that the camera can continue to do it's business. In that regard, it may be possible to push it a little bit. One way would be to change the uBasic code so that (for example) it gets called every 5 msec. If this is not possible, perhaps some functions can be coded so that they let uBasic do two things in one time slice (for example, where the function is merely to read and return a system variable, it quickly does so and then makes uBasic do another line; whereas if the function is a more time consuming task, it doesn't do this.) I can now see the utility of functions that combine tasks, like the set_focus_rel, which does in 10 msec what a get_focus x, x=x+change, set_focus x would need 30 msec for. Thus, there may be stratgies for speeding things up, yet let the camera maintain itself.